SPACE 2/SPACE - Library 2 - Volume 1.iso/program/712/code.txt

Text File | 1993-05-27 | 5.4 KB | 136 lines

Path: news1.cis.umn.edu!umn.edu!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!ux1.cso.uiuc.edu!uwm.edu!caen!batcomputer!munnari.oz.au!bunyip.cc.uq.oz.au!uqcspe!cs.uq.oz.au!warwick
From: [e-mail] (Warwick Allison)
Newsgroups: comp.sys.atari.st
Subject: Re: Cross compiling with GNU C for ST?
Message-ID: <[e-mail]>
Date: 21 May 93 01:17:01 GMT
References: <1t9akh$[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Lines: 124

[e-mail] (Greg Comeau) writes:

>[e-mail] writes:
>>You could just use my GEM++ C++ class library (written in GNU C++ of course).

>I'd be interested in hearing more about this, and AMS.

Greg may have intended to email, but I think this is worth posting anyway.


I am a strong believer in sharing code.  And I think C++ is THE language for
doing it.  The reasons are:

    1. It is as popular as C (or at least, it shortly will be).
        - You need a userbase in order to share code
    2. It has a high level of information hiding - encapulation.
        - You need this, or else chaos eats you up.

Now, it seems to me that there are three types of applications written for the
Atari computers:

    1. Machine independent (eg. all the ported GNU tools)
    2. GEM dependent (all those nice apps that run on all screen sizes)
    3. Machine specific (they run in only one or two fixed resolutions)

For (1), you can use all the world's class libraries.

For (2), I wrote GEM++.
For (3), I wrote AMS.

>Any chance of giving a "mild" example, maybe a screens-worth [of GEM++]?

Here is some example code I just made up:

-----------------------------------------------------------------------------

    main()
    {
        // Before we do ANYTHING with GEM, we must declare a GEMapplication.
        // This does the old appl_init/appl_exit stuff for us.
        GEMapplication example;

        // Create some GEMrsc objects (they load RSC files)...
        GEMrsc rsc1("example.rsc",8,16);
        GEMrsc rsc2("exam2.rsc",8,16);

        // Create some GEMform objects from those GEMrsc objects
        // by simply using the RSC indices that we used in the
        // RSC editor.
        GEMform form1(rsc1,FORM1_RSC_INDEX);
        GEMform form2(rsc2,SOME_OTHER_INDEX);

        // We can make a complete COPY of a form very easily...
        // This copies all the user-modifiable parts of the form,
        // but can just share the original copies of constant things
        // like titles strings, etc.
        GEMform anotherform=form1;

        // To use forms, we just "Do" them...   [ SEE NOTE 1 ]
        form1.Do();         // (centred)
        form1.Do(100,30);   // (at a given position)

        // If we declare GEMobject objects :) in the GEMform, we
    // can find out more via those GEMobjects.  Again, we simply
        // use the RSC indices to refer to objects...
        GEMobject the_okay_button(form1,OKAY_BUTTON);

        if (the_okay_button.Selected()) {
            printf("OKAY selected\n");
        }

        // More interesting than GEMforms, are GEMformwindows, which
        // are just like GEM forms, except they are in a window.
        //
        // To use GEMformwindows, we need a GEMactivity in which the
        // windows act.  This encapsulates all the event handling
        // code, and all those ugly low-level things that C GEM users
        // had to deal with.
        GEMactivity activity;

        // Then, all we do to have a window is say which GEMactivity
        // it is in, and get the graphics out of a GEMrsc.
        GEMformwindow my_window(activity,rsc1,MY_WINDOW_INDEX);

        // Open the window...  [ SEE NOTE 2 ]
        my_window.Open();

        // And set it all in motion...  [ SEE NOTE 3 ]
        activity.Do();
    }

NOTES:
    1. Normally, the user will create a derived class of GEMform
        that encapsulates the actions that need to happen when
        the user interacts with a form.  This is done by overriding
        the virtual method "DoItem(int item, const GEMevent& e)",
        or by declaring actuve GEMobjects in the form.  But here,
        for simplicity, I have shown GEMforms being used directly.
    2. Cleverly, GEM++ only calls the GEM "wind_create" funtion
        when a window is actually opened.  This way, you can have
        any number of "GEMwindows" (of which GEMformwindow is one type)
        and only the OPEN ones will take up GEM window handles.
        (which are limited in some TOS versions)
    3. Normally, the user will have other things like a GEMmenu
        object, maybe a GEMdesktop [though not advisable under
        MultiTOS!], other windows, etc. in the activity.

-----------------------------------------------------------------------------

>Do you use any of the g++ extensions/incompatibilities?
>I ask this as I'd imagine that if it didn't, that it would
>probably mesh with Comeau C++ 3.0 With Templates reasonably.

I have tried to avoid any dependence on GNU C++, but only having one
compiler to check against, I guess some minor dependencies may exist
(ie. bugs in my code that G++ lets slide).


--
Warwick
  _-_|\      [e-mail]            ||||||  AMS  = C++ game library   |
 /     * <-- Computer Science Department,   |||||| GEM++ = C++ GEM library    |
 \_.-._/     University of Queensland,    _// || \\_   Both are GNUish = Free |
_____ v ____ Brisbane, Australia. ______ |_/  ||  \_| ________________________|